The Xtender ("cross-tenant data exchanger" ) engine allows clients with many tenants, who use single tenant data sources, to use a singular semantic model and analytics catalog across all tenants, by auto-switching the underlying data source for each tenant. Xtender for Databases is designed to switch out the database, rather than the data source instance.
Xtender only operates well if the reports and semantic model are virtually identical between customers. Automatic column handling in the semantic model may be able to account for some variations.
Note: The Xtender engine is licensed separately.
- Click here to see the Xtender guide.
Enabling Xtender for Databases
To enable Xtender database, choose the 'Database' mode from the drop down on the General setting tab of the data source card.
Once you have enabled the Xtender 'database' option for this data source, you will see an extra tab in the database section of the data source manager. You simply need to add alternative database names to be used for this primary database for each tenant. As users connect from their respective tenants, the queries will be redirected to these alternative databases instead of the original.
If no database name is supplied, the connection reverts to the original primary database name.
Examples
Extending by Database
A clothing manufacturer “Omega Stitch” fulfils requests for multiple external corporate clients , the manufacturer allows each client to access analytical data regarding their orders via their Pyramid instance.
Each clients data is held within its own separate database on the manufacturers IMDB server, which is located on a tenant called “OmegaStitch”.
The manufacturer employs a standard database schema for each of its clients within an IMDB data source hosted within the “OmegaStitch” central tenant.
The deployment of the Xtender engine in “Database” mode, allows for the manufacturer to create a common semantic model to provide a standard platform for the reporting content to be created upon. The Xtender service redirects the requests to the client specific database.
For this example there are 3 clients , Iota Sports, Kappa Clothing and Lamda Athletic. Each client has their own tenant on the Pyramid platform where their user ids will be located.
Pre-requisites
To allow for the end users to access a common semantic model, databases and data sources across a number of tenants the instance must be enabled for cross tenant roles and cross tenant content.
This is configured within the admin console, see Content Settings for more details
Configure Xtender on the ‘Master’ tenant data source
To allow Xtender to control the redirection requests of database requests to other databases based upon the tenant a user belongs to, we need to configure the data source containing the database to be redirected (and thereby any data model based on that database).
Within the admin console > Data Source, within the “Omega IMDB” data source and the General settings tab the “Xtender Engine” is configured to function in “Database” mode.
Configure Xtender mapping on the ‘Master’ database
The Xtender feature requires mapping a data source to the relevant client databases. To achieve a common semantic data model, a master database is necessary for creating the model.
The 'OrdersDatabase' in the 'Omega IMDB' data source will function as the master database because it shares the same schema as the client databases.
The mapping configuration is done in the admin console: Source Manager. Within the master 'OrdersDatabase', the 'Xtender Databases' tab allows you to map the databases for each client tenant.
The configuration settings redirect users based on their tenant. For example, users from the 'Iota Sports' tenant connecting to the 'OrdersDatabase' database are redirected to the 'IotaSports' database. Users from the 'Kappa Clothing' and 'Lambda Athletic' tenants are redirected to the 'KappaClothing' and 'LambdaAthletic' databases, respectively.
Additionally, the roles from the client tenants must be added to the master 'OrdersDatabase' database with 'Read' permission. This is only necessary for the master database; client roles do not require permission for databases that are targets of redirection from this database.
Semantic Model
Semantic models created against the master 'OrdersDatabase' database will source their data from the configured redirected databases. Consequently, no additional Pyramid-specific configuration is needed for the model or any related content (such as dashboards) to utilize this. The only requirement is that the roles from the client tenants have 'Read' permission to the semantic model.
Example of a user from Kappa Selling accessing analytical content connecting to the common semantic model connected to the master database ‘OrdersDatabase’
